Project Introduction and Goals
For this project under INEG 22203 at the University of Arkansas, our team developed a vehicle decision and analysis system that helps users evaluate vehicle options for different travel situations. The system uses a vehicle fuel efficiency dataset stored in a CSV file, from the kaggle source linked below. The data includes information such as vehicle class, cylinders, displacement, city MPG, highway MPG, and drivetrain. The purpose of our project was to take said vehicle data and turn it into an interactive tool that could recommend vehicles, give our user feedback on fuel efficiency assumptions, predict MPG for a new vehicle, and estimate trip capacity based on specific needs like a budget.
Industrial Engineering Concepts we Followed
Throughout the steps in our project, we used decision making based on data, constraints, and weighted preferences. Several parts of the project work like a small optimization problem, where the program filters out incomplete or messed up data points, then ranks the remaining options based on the user’s priorities. The project also connects to statistical modeling because we used summary statistics and regression to compare groups and predict fuel efficiency.
Specific skills developed
Important skills we showed during this project include creating custom Java classes, organizing logic across multiple files (with some trial and error), using ArrayLists to store loaded vehicle data, reading and cleaning CSV data with OpenCSV, building a Vaadin interface, and figuring out our best way to collaborate and stay involved through GitHub. We also practiced converting real variables into program logic, such as estimating passenger capacity, luggage capacity, comfort, range, and speed from the available vehicle data.
Development Process
Our original goal was to create a program that could answer the question: “What is the most efficient vehicle to use for a trip given the passenger count, distance, and cargo amount?” At the beginning, this seemed like mostly a filtering problem, but as we developed the idea it became more complex. We realized that “efficient” does not mean the same thing for every user, so we added weighted preferences for fuel efficiency, comfort, range, and speed. The design evolved as we added more functionality. The first version focused on loading the data and recommending a vehicle. Later, we separated the project into different classes so each part had a clear job. DataLoader handles reading and cleaning the CSV file, Vehicle stores vehicle information and derived values, TripRequest stores user input, VehicleRecommender handles filtering and scoring, VehicleAnalysis handles group comparisons, RegressionModel handles MPG prediction, and BudgetTripPlanner handles the budget functionality. While this structure made the project easier to debug and expand, it also greatly helped whenever we wanted to check our overall progress, find something from an earlier part, or navigate around the repository without spending excessive time searching.
Roadblocks and “Hiccups”
One roadblock we crossed throughout our process was related to our weighted scoring system. Initially, there was a wedged gap in the categories with inherently smaller vs inherently larger numbers. For example, categories like fuel range and trip distance have much larger numbers than MPG or speed, which caused uneven scoring in the weight system. We fixed this by scaling values and using normalized weights so each preference could affect the result more fairly.
In the end, our produced product mostly matched our expectations, but it did change in some places. While the initial idea was a recommendation tool, it grew into a larger decision making system with our separated interface pages. Additions that were made included a regression based MPG predictor and the budget planner. Overall, the project became a more complete “system” compared to the original, more basic idea.
Key features and highlights
One feature is the weighted recommendation system. Our user enters their passenger count, luggage size/amount, and their personal preferences for fuel efficiency, comfort, range (without refueling), and speed.The program filters out vehicles that do not meet the passenger and luggage requirements, then scores the remaining vehicles. This is one of our key sections because it is what separates the program away from a simple filtering and transforms it into a personal tool.
Another important feature is the trip-specific MPG calculation. Instead of only using city MPG or highway MPG, the program changes the MPG calculation based on trip distance. Shorter trips are based largely on city MPG, while longer trips give more importance to highway MPG. This makes the model more realistic, as a long range trip is unlikely to spend much time rolling through cities.
The fuel-efficiency analysis tool is another feature we are proud of. It allows users to select a vehicle class and drivetrain, then compares the selected group’s fuel efficiency to the overall dataset. This helps test assumptions such as whether SUVs or AWD vehicles are always much less efficient. This part shows how the project uses data analysis rather than only recommendation logic.
Our regression model is one of our highlights with the longest code. The model predicts city and highway MPG using vehicle class, cylinders, and displacement. Since vehicle class isn’t a number, we converted it into a numeric value and normalized the inputs before training the model. The model then calculates predictions and reports evaluation values such as MSE and the R square value. This was one of the more advanced parts of the project because it required matrices calculations and logic.
The budget planner is useful because it reverses the original recommendation problem. Instead of asking what vehicle best fits a given passenger and luggage requirement, the user enters a trip distance, budget, and gas price. The program then finds which vehicles can complete the trip within budget and reports the maximum passenger and luggage capacity possible. This made the project more flexible and added a new perspective.Some code screenshots are copied below that cover these snippits.
DataLoader Cleaning
Regression Development
Budget Modification
Reflections and Final Thoughts
One main code aspect I expanded on in this project was having all the separate class files working in conjunction. Also, learning how to code regression. My individual contributions are on the scoring system, some of the DataLoader concepts, large parts of the regression, working on cleaning the dataset, and portions of the final Vaadin interface. I grew as a coder because I became more comfortable working with multiple classes, ArrayLists, CSV input, and larger project organization. I also became more confident debugging issues that came from mismatched data, missing values, and logic that worked mathematically but did not behave as expected at first. At the start, the project felt like a simple vehicle recommendation idea, but by the end I felt more confident building a larger program with multiple connected features. Finally, I am proud of how the formatting of the produced results looks on the interface as well as the decisions we made mathematically and stylistically.